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Chapter 1 
Introduction 



Building Trust is the basis of all communication, especially electronic one, as the identity of the 
other entity remains concealed. To address problems of trust, authentication and security over 
the network, electronic communications and transactions need a framework that provides security 
policies, encryption mechanisms and procedures to generate manage and store keys and certificates. 

The Public Key Infrastructure (PKI) is a security architecture that has been introduced to pro- 
vide an increased level of confidence for exchanging information over increasingly insecure networks, 
such as the Internet. A PKI infrastructure is expected to offer its users a secure and trustworthy 
electronic transaction. 



1.1 Purpose 

The intent of implementation and deployment of PKI facilities is to meet its basic purpose of 
providing Trust. Presently, PKI needs to perform the following security functions: 

• Mutual authentication of entities taking part in the communication: Only authenticated prin- 
cipals can access files to which they have privileges. 

• Ensure data integrity: By issuing digital certificates which guarantee the integrity of the public 
key. Only the public key for a certificate that has been authenticated by a certifying authority 
should work with the private key possessed by an entity. This eliminates impersonation and 
key modification. 

• Enforce security: Communications are more secure by using SSL to transmit information. 
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1.2 Scope 

PKI is implemented to secure sensitive resources of the organization and avoid security breaches. 
The PKI environment allows trustworthy communication between the different principals. These 
principals must be authenticated and the access to the resources (files) should be secured and 
regulated. Any principal wants to access to the database needs to perform the following steps: 

• Mutual authentication: The Web Server via which the database is contacted authenticates 
the principal using its digital certificate and username to ensure that it is who it claims to be 
. The principal authenticates also the server using its certificate information. 

• Principal validation: To validate the principal, the server looks up information from an LDAP 
server which contains the hierarchy of all principals along with certificates and credentials. 
The LDAP service is compliant with the X.500 database structure. 

• Enforcing security: The security is enforced by using SSL to communicate between the Web 
Server and the LDAP server, the Web Server and the database and between the principal 
and Web Server. 

• Principal authentication: Upon successful authentication, the Web Server will allow the prin- 
cipal to perform actions on the database according to a pre specified Access Control List. 

• Kinds of users: We distinguish between a normal and an administrator. While a normal user 
can upload, download, delete and view files; the administrator has the ability to: upload, 
download, delete and view files; add, delete and modify users; generate user's certificate, with 
all required information; generate ACL to users; manage groups, perform maintenance. 

Finally, this infrastructure allows additional features such as the ability to assign users to groups 
in order to provide users with the access to files prepared by other group members. 

1.3 Definitions and Acronyms 

• PKL Pubhc Key Infrastructure 

• OpenLDAP : is a free, open source implementation of the Lightweight Directory Access 
Protocol (LDAP). 

• OpenSSL: an open source SSL library and certificate authority 

• Apache Tomcat: A Java based Web Application container that was created to run Servlets 
and JavaServer Pages (JSP) in Web applications 
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• PostgreSQL: An open source object-relational database server 

• SSL: Secure Socket Layer 

• JSP: Java Server Pages 

• JCE: Java Cryptography Extension 

• APL Application Programming Interface 

• JDBC: Java Database Connectivity 

• JNDL Java Naming and Directory Interface 

• LDAP: Lightweight Directory Access Protocol 

• X.509: A standard for defining a Digital Certificate used by SSL 

• SRS: Specification request Document 

• SDD: Specification Design document 

• DER: Distinguished Encoding Rules 

• Mutual Authentication: The process of two principals proving their identities to each other 

• SFS: Secure File Exchange Server, this product 

• COTS: Commercial Off The Shelf, common commercially or freely available software 



Chapter 2 

System Architecture 



This chapter is intended to provide an overview of the whole system as proposed in the previous 
requirements and specification document. It describes the product's perspective, interfaces and 
design constraints as we have assumed. We will first describe the architectural guidelines for this 
product, followed by software interface design design, and hardware environment. 



2.1 Architectural Philosophy 

The SFS technology hereby implemented is running on architecture that provides a high level of 
secrecy and integrity for exchanging information. The system is externally visible only through a 
web application for normal users, and is also entirely visible and accessible for administrators in 
the scope of normal operations. In addition, the system assumes an internal certificate authority 
which is explicitly trusted by all principals using SFS. 

For the proposed architecture, it requires mutual authentication between the user and the web 
server, an LDAP validation of the user by using digital certificates, the use of the SSL protocol 
to enforce the security over the communication between modules and the preservation of files in a 
database. 

This architecture must respect the following properties: 

• Security: The confidentiality, integrity and availability of information. This is to be imple- 
mented by supporting the data encryption and certificates mechanisms for secured commu- 
nication, as well as specifying an access control mechanism for the files stored 

• Trustworthiness: The use of electronic certificates internally generated, and of specific use for 
the application, allow an high trust to be given to the user. 

• Scalability: SFS can be expanded easily to cope with large loads. Methods such as load 
balancing and replication can be easily integrated. 
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• Openness: The proposed architecture can be implemented and deployed using Java Tech- 
nologies and open source tools that are well-used and rely on standards. The SFS itself is an 
open source product developed to achieve security objectives. 

• Component- Based Software Engineering: The SFS framework may be treated as components 
(modules) . We have already mentioned the relevant technologies that can better fit for each 
of these modules. 

• Usability: The SFS service must be designed for high usability. All the required information 
for a single operation should be grouped in a single screen, with a minimum number of screens 
needed for all the application. 

This architecture aims at maximizing software reuse by the integration of COTS applications, 
portability and interoperabihty by the use of standards, security and scalability by the user of a 
single access point. 



2.2 Components 



The Figure 2A_ describes the overall architecture of the SFS system. We see four major inter- 
acting components: the user interface, the web server, the database and the LDAP server. Two 
components are not displayed on this figure , which are the certificate authority and the logging 
engine. 



2.2.1 User Interface 

The user interface constitutes of HTML web pages that the user uses through a web browser. Those 
web pages are generated by the web server and interact exclusively with the SFS web server. 



2.2.2 Web Server 

The web server is the single access point of the system. It handles authentication responsibilities, 
database access and user interaction. This is to be handled by the Apache Tomcat 5.0 server and 
custom J2SE 5.0 code. 



2.2.3 Database Server 

This database server contains all the information about the files and their access control rights. It 
contains also a subset of the user information. This is to be handled by PostgreSQL. 
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Figure 2.1: Main system architecture 
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2.2.4 LDAP Server 

This specialized server holds the user credentials (notably user name and password). It could be 
extended to include user certificates. This module will be realized by OpenLDAP. 

2.2.5 Certificate Authority 

This responsibility is manually managed by administrators. Using software tools, they are able to 
generate the user and server certificates. In our case, we use OpenSSL to perform those functions. 

2.2.6 Logging Engine 

This component is responsible for collecting the audit trails and debug information from other 
components and store it locally. We wanted to use log4j, but we finally opted for the logging 
mechanisms available in the tools we are using, notably by using Tomcat's logging. 

2.3 Interactions 

We will now describe the inter-module interactions by the use of a system scenario. 

The user, with a web browser, connects to the web server using SSL. The web server, being 
configured as to require client authentication, both parties exchange their certificates and validate 
their peer's identity. The web server then prompts the user for a user name and password, thereby 
enforcing 2-f actor authentication. 

Upon receiving this information, the web server queries the LDAP directory based on the user 
name and retrieves the user's password hash and certificate (if any is defined). The web server then 
proceeds to hash the plaintext password (using SHAl) received from the user and compare with 
the one from the LDAP server. If that information (as well as the certificates, if any) matches, the 
user is logged in the system. 

The web server will then query the database server for the access rights of the user (adminis- 
trator or normal user) and the list of files the user has access to. Based on this information, it will 
display the appropriate user interface functions and the file list. 

On user requests to upload, delete or download files, the web server will request the database 
server to perform the needed transactions. 
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2.4 Software Interface Design 

This section describes the software interfaces (commonly referred to as APIs) to be used to com- 
municate between each component. 

2.4.1 Web Server 

The web server is reached by the chcnt through an HTTPS connection to the single point of access 
for the web application, the login screen. 

2.4.2 Database Server 

The database server is reached using the JDBC API with the official PostgreSQL JDBC driver. 

2.4.3 LDAP Server 

The LDAP server is reached using the default Sun LDAP JNDI driver. The LDAP protocol is used 
for the queries and is encapsulated by JNDI. 

2.4.4 Certificate Authority 

This component is not integrated with others and, as such, does not have a software interface to 
document. 

2.4.5 Logging Engine 

On the Web server, this component is called automatically by the use of the default output and 
default error streams, which will write the information to a log instead of a console. 

2.5 Hardware Environment 

The SFS system is expected to work in a networked environment, possibly a LAN, but not nec- 
essarily. We assume that the principals have a network connection allowing to communicate with 
each other. Only typical low-end workstation hardware (such as a Pentium III system with 256-f- 
MB of RAM, 2GB hard drive with a lOBaseT Ethernet connection) is required to operate all the 
components of the system, which may be distributed or centralized as needed. Ordinary P III with 
256-1- MB of Ram and 2GB HDD are the minimum requirements needed to deploy the system. 
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2.6 Code View 



We decided to structure our software in a few main packages, as illustrated in Figure 2.2 




Figure 2.2: Java Packages 



Those packages hold as follows: 

1. securefileserver: root of our custom code 

2. base64: Library for encoding and decoding Base64-encoded data 

3. apps: Various applications 

4. webapps: The web application code 

5. conn: Connection abstraction code, such as SSL connections, LDAP connections and database 
connections 

6. cert: Certificate authority code 

7. util: Utility classes, such as the configuration file loader 

Since we had to deal with a large set of non-code artifacts, we structured our repository as 



illustrated in Figure 2.3 



Those directories hold as follows: 



Simple Secure Web-Based File Exchange Design 



l^conf 

(^images 
l^lib 

1^ build, xml 



Figure 2.3: Repository Structure 



1. root directory: contains the Ant makefile and all the other subdirectories 

2. cert: certificates generated manually using OpenSSL 

3. conf: configuration files 

4. CVS: repository management code, handled automatically by CVS 

5. images: documentation-related images 

6. lib: libraries in JAR format 

7. sql: database initialization script 

8. src: Java source code 

9. tex: documentation in lOTEX2e format 

10. txt: various notes in text format 

11. design: Rational Rose model of the system 



Chapter 3 



Detailed System Design 



In this section of the specification document we elaborate the detailed description of the main 
modules and subprograms of the SFS system. We provide the important class diagrams for the 
different packages of the design phase as mentioned above. 



Please consult Figure 3.1|for a high-level view of the class diagram of our application. Please 



note that the servlets login and User also have a fair amount of business logic integrated in them. 
This situation is due to the evolutionary nature of the development method used in this project 
which, combined with tight deadlines, did not allow for a proper refactoring of the classes. 

We can also take note the presence of test classes in our class diagram, which are JUnit test 
cases that allowed to perform some unit testing. The smallness of the class diagram is mostly 
explained by the fact that most of the functionality was implemented in COTS programs that 
needed only some configuration. 

3.1 Class Diagrams 

The following diagrams show some of the important user interfaces of the SFS software system. 

3.2 User Interface 

The following diagrams show some of the important user interfaces of the SFS software system. On 



figure 3.6, we see the interface allowing clients to log in. 



Once the client mutual authentication is achieved and user allowed to use the system he will 



get the following screen (3.7). 
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,HS 



User 



DatabaseConnection 

[from 00 nn) 



*DatabaseConnectionO 

^DatabaseConneclionQ 

*DatabaseCoririec1ioriO 

^getConnectionO 

*setCorinectionO 

*getStrOatabase() 

^setSttOatabaseQ 

*getStrOwerO 

*setStrOwer() 

^closeO 



LDAPConnection 

(from conn) 


UseiCredentials 

(from conn) 


^LDAPConnectionO 

^connectQ 

^removeUserO 

^queryUserlnformationO 
^createUserEntryO 


^UserCrederitialsQ 
*UserCrecleritialsO 
■i^extraclPasswordlnformalionO 
^getNameQ 
*getPa££wordHashO 
*getCertificateO 
^getPasswordTypeQ 
*equalsO 

^hashPasswordWilliRandomSaltO 
^oStringO 





SSLConneclion 

(from conn) 



■^setSSLConnectionQ 
^getSocketFacloryQ 



KeyStoreGenerator 

(from app;) 



*mainO 



SelfSignedCertGenerator 



■ik^strPassPhrase : String = "lv1@$lv1@bDb" 
■^strCommonName : Siring - "Mr. Self Signed" 



■^signExlernailyO 
^mainQ 



OpIionsFileLoaderSingletonTesI 



^estLoadConfigurationString 



OptionsFileLoaderSingleton 



1?*OptionsFileLoaderSingletonO 

^ioadConfigurationO 

*gelCorifigurationSettirigO 
1?*re m ve C m m e nt 
^gelKeyO 
'^gelValueO 

^islnitializedO 

*ge1ln£tanceO 

*loadConfigurationO 



#$nioOptionsLoaderlnstarice 



BaseB4 

(from bjse64) 



^Base640 
^encode3to40 
^encode3to4Q 
^encodeBytesQ 
^encodeBytesQ 
*encodeBytesO 
^encodeBytesQ 
^decode4to30 
^decodeQ 
♦decodeO 
*decodeToObjectO 
^encodeToFiieQ 
♦decodeToFiieQ 
♦decodeFromPileO 
^encodeFroniFileO 
^encodeObjectQ 
*encodeObjectO 



Figure 3.1: SFS main class diagram 
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conn DatabaseConnection 

ffrom ocnnj 

■^strDriver String 
^k^strUser : String - "sfs" 
■i^strPassword : String = "lv1@$ni@bDb" 
^ DEFAULT_DRIVER : Strings "ora.postgresqi.Driver" 

# DEFAULT_DATABA5E : String = "jdbc:pQstgre£ql://lQC3lhQ£t/sf5?5sl=truegL££lfactQry=Qrg.pQ£tgre£ql.££l.NQnValid3tingFactQry" 
'i^£trDataba£e : Siring 



''^Databa£eConnectioriO 

^DatabaseConnectionQ 

^DatabaseConnectionO 

^getConnectionO 

^setConnectionQ 

^getStrDatabaseO 

^£etStrDataba£eO 

^getStrDriverO 

♦£etStrDriverO 

^clo£eO 



LDAPConnection 

(from conn) 

^ SUBJECT_NAME_QUERY_A^RIBUTE . String ^ ^^uld'^ 
^ CERTIFICATE QUERY AKRIBUTE : String = ^^userCertilicate'^ 
^RASSWORD_HASH_QUERY_AKRIBUTE : Stnng ^ "userPassword" 
^OBJECT_CLASS_ATTRIBUTE : Stnng = ■'objectCla££" 
^OBJECT_CLASS_ATTRIBUTE_DEFAULT_VALUE : String = "inetOrgPer£on" 
^SN_AnRIBUTE . String = "sn" 
^CN_AmiBUTE : String = "cn" 
'^QUERY_DOMAIM : String = "dc=mycompany,dc=com" 
^NEW_ENTRY_SUBCONTEXT : String ^ ".ou^people," + QUERY_DOMAIN 
^TEST_WITHOUT_SSL : boolean = fal£e 



*LDARConnectionO 
*connectO 
^removeUserQ 
*clo£eO 

*querYU£erlnformationO 
^createUserEntryO 



SSLConnection 



IJ^setSSLConnectionO 
^getSocketFactoryO 



UserCredentials 

Ijf'omconn) 

■SsmstrUserName : String 
'^m£trPa££wordHash : String 
■^miPasswordType : int 
* RASSWORD_RLAIN : int = □ 
^ PASSWORD MD5 : int = 1 
* PASSWORD_SHA : int = 2 



*UserCredentialsO 
^UserCredentialsO 
'i^extractPa££wordlnformationO 
^getNameQ 
*getRasswQrdHashO 
*getCertificateO 
^getPasswordtypeO 
*equal£0 

*ha£hPa££wordWitliRandomSaltO 
^oStringO 



Figure 3.2: Conn Package Diagram 



KeyStoreGenerator 

(fromapps) 



*mainO 



Test DatabaseConnection 

(from apps) 



*mainO 



User 

5m webapp) 



Figure 3.3: Application Package Diagram 
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PrincipalAthenticator 

(from util) 



^authenticateQ 
^connectQ 



TestSSHA 

(from util) 



^ hearts : Siring = "□12345E789abcdef' 
^bVerbose : boolean = false 



♦TestSSHAO 
^createDigestO 
^checkDigestQ 
^setVerboseQ 

^concatenateQ 

^splitO 

#toHexO 

^romHexQ 

*mainO 



OptionsFileLoaderSingleton 

(from util) 



^ DEFAULT CONFIG FILE NAME: Siring = 'Vusr/share/lomcalS/bin/.confia" 

^ COMMEMT SYMBOL : ohar = 

^ SEPARATOR SYMBOL: cliar=^' 
^ LDAP SERVER NAME KEY : Stnng = "lijap server" 
# CA SERVER NAME KEY : String = "oa serjer" 
# DB SERVER NAME KEY : Slnng = "db server" 
^ KEYSTORE FILE NAME KEY : Stnng = "kevstore filepath" 
# KEYSTQRE PASSWORD KEY : Strina = "kevstore password" 
# CA SERVER CERTIFICATE FILE : String = "ca certificate flepath" 
» LDAP_PRINCIPAL_NAME_KEY : Stnng = "ldap_pnncipal" 
# LDAP PRINCPAL PASSWORD KEY : Stnna = "Idap password" 

?#oHashOptionValLePairTracker : Hashtable 

'^blslnitialized : boolean 



f*OptionsFileLoaderSingletonO 

^loadConflgurationQ 

^getConfigurationSettingO 
■^removeCommentO 
1*getKeyO 
^♦getValueO 

^islnitializedO 

*getlnstanceO 

^loadConf gurationO 



1^ 



#$oOptionsLoaderlnstance 



Figure 3.4: The util Package Diagram 



SelfSignedCert General or 

l^strPassPhrase : Siring = "M@JM@bDb" 
'5i>strCQrTimonNarTie : String = "Mr. Self Signed" 



^signEifternallyQ 
^tnainO 



Figure 3.5: The cert Package Diagram 
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^ Secure SSL File Server Demo Microsoft Internet Expio 




: File Edit V\ew Favorites Tools Help 


\ 0B,k ■ Q - \^ :i 


y. ' Search '-^J^ Favorites Media 


0'^ a -Dil 



j Address |^ hti:ps;/;gunnymeder 



ordia,ca:8443/5f5/bgin.]5p 



j Links @ Cusl:oniee Links ^ Free Hotmail Windows Windows Media 
I - I Rechercher ' iJ'" ^Anti-5py 



jjvi Signets ' ©MonVahooi - Wahoo! - Finance - El] V! Mail 



A Meant To Be Secure File Server (SFS) 
Web Application Demo v.0.0.1 

Yo! Wanna transfer some files ova SSL? Login, sweetie,., 



User Name:[] 
Password :[] 



Copyleft 2005 The CIISE Security Investiagtion Initiative 



Figure 3.6: User interface Log on 



3 SFS - File Info - Microsoft Internet ExplorE 



File Edii: View Favorites Tools Help 



©Back ' ■ >)5earch V^Favorlt« ^ Media €>| ^ ■'□19. 

https://gunnymeden,encs. Concordia, ca 184 't3/sfs/login 
Linhs ^ Customize Links i Free Hcil:mall .-tj Windows Windows Media 

' I ^Rechercher' ^Anti-Spy - | (j^YI Signets ^ ©MonYahool ^ "^Yahool -■ ^Finance ^ ^VIM 



Welcome test 

I Admin Form ] 



Select File to Download or Delete 

O Test3 txt 

O init.sql 

O build. >anl 

® I 1 ^7-jones.pdf 

Ohmjpg 

G mokhovjpg 

O user. txt 

O ca.crt 



DownloQd ][ Delete | 



A»iicli file fo upload 



Figure 3.7: User operations displayed 
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When the chent chooses the file to download, he will be prompted to open the file or give the 
path he want to save the file in. 



1 SFS File Info Microsoft Internet Explorer 



; File Edit View Favorites Tools Help 


i . o a @ 


Seerch Favorites Media 




: Address ^ tilitps: //gunnymeden . encs .concordia . ca ; 84 43 /sf 5/ login 


: Lirihi ^ Cijstorrii:e Links _. Free Hotmail 


_. Windows ^ Windows Media 




i V? - !^-l 


Rechercher ' ;^Anti-5py ' (^Yi 5igne 


s' ©MonYahool ' WVahooi ' ^Finance ' OV!M 



Welcome testOH^^^^^^^^^^E 




grpA 

1 Admin Form | 


*f J Some liles oan liaimyoLir computer II the file infcrmalion below 

looks suipicioijs. 01 VOL! do no! fully trust the source, do no! open or 
save this file 

File name: U5erfe5e9a55 

File type Adobe Aacbai: Control for Achve>: 

Fiom: gun nymeden. encs, concordia. ca 

This lype ol file could harrryoui computer if il conteins 

Would you like to open the lile or save it to your eompijter? 




Select File to Download or D 

Test3 M 
initsql 
build ]iml 
■ ©ipl97-jones.pdf 
brain.jpg 
mokhov.jpg 
user.M 




1 i3pen 1 Save | Cancel | Moielnfo | 


Always ask before opening this type ol file 



O ca at 



I DownlGad""!! Delel~ 



Attach file to uplo^nl 



Figure 3.8: User operations displayed 



Figure |3.9| shows the upload operation, so the user will be prompted to select the file he want 
to upload. 



Figure |3.10| shows the administrator capabilities: adding users, remove users, adding groups, 
setting rights, etc. 

The snapshot of the SFS provides the login interface via which the services of the SFS system 
can not be utilized unless the user is already logged in. 



3.3 Class Diagrams 



Figure 3.1 includes most of the classes already present. We will describe a few classes in detail 



here. All the details regarding the classes are available in the Javadoc. 



3.3.1 LDAPConnection 

This class provides an abstraction of an LDAP JNDI context, as well as pre-made queries for 
obtaining user credentials, deleting an user and adding an user in the database. 
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3 SFS -- File Info - Microsoft Internet Explori 



File Edit View Favorites Touls Help 



@Ba* - O - m i'iil P="-h -f^F^-^rMs |J|» Madia ^1 ^ ■ ' □ IS. 



Address ^ https ; //gunnymeden . encs . concordia .ca ; 84'13/5f 5/login?submit=bt 



Links ^ Customize Links 



|] Free Hotmail ^ Windows ^ Windows Media 



- Finance - ^ Y! 



Select File t( 



O Test3.txt 
O mit.sql 
O build. Kml 
O pl97-jones.p 
O brain.jpg 
O mokhov.jpg 
O user.txt 
O ca.crt 
O nuU 



Download 



Attach file tn 



Look in: Q INSE6100 Reporl 



a 

Recent 

m 

Desktop 

3 

Mil Documents 

Mil Computer 

Mil Neti/oork 
Places 



aaaa.tex 




B adduser 


Report 


[*] admin 


^ Report. aux 


B architecture 


Report. lof 


B deleteuser 


Report. lot 


Design Views.tex 


^ Report.tex 


§ER 


dll] Report. tex.bak 


Q.ER 


M Report. toe 


Qero 


i^5dd_project 


Pli login 


Untitled-2 


Wimain 


^USE_CASE 


[*1 modif yuser 




1*1 packages 




■^1 Report 




1^ Report 





File name: 
Files of tvpe: 



I Report 



"3 



Open 



I All Files {;:■] 



"3 



Figure 3.9: User operations displayed 



It depends on SSLConnectionFactory for ensuring that our SSL Connections are set with the 
proper keys. It also depends on UserCredentials, since this is the data type it returns on a query. 

3.3.2 UserCredentials 

This class encapsulates a user name, a password, and a certificate. It integrates the hashing of 
plaintext passwords, as well as a matching comparison between two sets of credentials. It depends 
on TestSSHA for generating and validating the salted SHAl hash. 

3.3.3 OptionsFileLoaderSingleton 

This class is a singleton, meaning that only up to one instance can exist at any time. It loads and 
parses a configuration file. It also includes many default keys of the configuration file as constant 
strings. 

3.3.4 DatabaseConnection 

This class provides an abstraction for an SSL-enabled database connection. Contrary to LDAPCon- 
nection, it does not provide high-level methods in it, leaving to the calling code the responsibility 
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^ SFS Management Form - Microsoft Internet Explorer 



] File Edit View Favoriiies Tools Help 

I Address |^ hi:^ps://gunnvmeden.eni:s.i:oni:ordia .i:a;S443/sl^s/user 

i Links ^ Customize Links ^ Free Hotmail ^ Windows bj Windows Media 



Manage Users and Groups 



User Name | 
Password | 
Group 1 
Organization | 
City 1 


O Ali 1 

O DJamel 

O Serguei 

O Marc-Andre 

O test 

O Moo 

O Boo 


State 


[ Load User || Delete User ] 


Country I ** Two Digit Country Code 

1 Add User || Modify User | 





Manage Groups 



Group ID: 


O A == Administrator 
O U == User 
O F == Foo 
O B = = Bar 

A+ == A+ Students 

1 n„i„._r. 1 


|1 Ali 


A 1 


Group Name;| | 


[I All 


A+ 1 


1 Add Group 1 


TIAI 


F " 




2 DJamel 


U 


1 \<tpr:\ ' 


2 DJamel 


A + 



Figure 3.10: User operations displayed 
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to formulate proper SQL queries. 



3.4 Data Storage Format 

In this section, we provide a description for the database handhng the security aspect of the system. 
It consists of the following entity relation model. 



3.4.1 Entity Relationship Diagram 

The Groupe entity contains the list of groups a user may belong to. The User entity contains the 
list of users having right to use the system. The File entity contains information about different 
files a user can upload, download, delete and view. A user may be an Administrator or normal user. 
The other relationships (group.user, group_files) are defined between entities Groupe and User and 
Groupe and File to host different information related to both of them respectively. Hereafter, we 



provide in Figure 3.11 the Entity Relationship Model of the Security Database. 




Figure 3.11: Entity Relationship Diagram 



3.5 Options File 

A .config file is expected in the execution root in order to read the configuration options. 
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Lines can be comments (#), blank, or containing a key=value pair. 
The expected configuration options are: 

• ca.server: host name of the CA server. This option is reserved for future use. 

• db-server: host name of the database server. 

• keystore-filepath: relative or absolute path for the web server's keys 

• keystore.password: password for the previously specified keystore 

• ca.certificate.filepath: path to the CA certificate's keystore 

• ca^certificate^password: password for the CA certificate 

• Idap-password: administrator password for the LDAP server 

• Idap. principal: administrator user name for the LDAP server 

• Idap-server: host name of the LDAP server 



3.6 Directory Configuration 

The LDAP directory is to be structured in an abritarily manner, as the DN is not used in queries. 
However, the UID parameter is used for querying based on the user name. The user information is 
of type inetOrgPerson, with the fields uid, userPassword and userCertif icate for, respectively, 
the user name, its password (hashed with salted SHA) and its certificate. 



3.7 External System Interfaces 

The only externally reachable interface to the SFS system is the login page of the web application. 
This page should be located at /sf s/login. jsp. It is also symlinked to it via index, jsp. 



3.7.1 External Systems and Databases 

The SFS system is not designed for interacting with any other systems than those described as part 
of our architecture. 
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3.8 User Scenarios 

3.8.1 Typical Scenario 

1. User connects to remote server using a web browser on a secure connection 

2. User is prompted with a logon screen, and provides a username and password 

3. After validation, the user is logged as a normal user and is shown a list of files to which he 
or she has access to, as well as their rights 

4. The user chcks to download a file and, if the system validates its rights, the download begins 

3.8.2 Variant scenario 

4. The user chooses to upload a file and the upload begins. The file will be modifyable by the user 
and according to the default new file ACL. 

3.8.3 Variant scenario 

4. The user chooses to delete a file to which it has delete rights and the systems perform the 
deletion 

3.9 Administrator Scenarios 

3.9.1 Typical Scenario 

1. User connects to remote server using a web browser on a secure connection 

2. User is prompted with a logon screen, and provides a username and password 

3. After validation, the user is logged as an administrator and is shown a menu of options, and 
chooses to view a list of files in the system 

4. The user clicks on the user edit button and changes the access control list of the object. 
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3.9.2 Variant Scenario 

1. User connects to the certificate administration service and generate a certificate for a given 
subject tfirougfi a secure connection 

2. User connects to remote server on a secure connection 

3. User is prompted witfi a iogon screen, and provices username and password 

4. After validation, the user is logged as an administrator and is shown the menu 

5. The user clicks on the certificate edit button and is shown a screen of certificate maintenance 

6. The user uploads the certificate and the system binds it with the certificate's defined principal 
(or creates the user if none exists already) 

3.9.3 Variant Scenario 

1. User connects to remote server using a web browser on a secure connection 

2. User is prompted with a logon screen, and provides a username and password 

3. After validation, the user is logged as an administrator and is shown a menu of options, and 
chooses to edit the certificates 

4. The user chooses to remove the certificate from a given principal 

5. The user connects to the certificate administration service and issues a certificate revocation. 
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